0x00 kerberos协议

原理：KRB_AS_REP::Ticket::EncryptedData是通过域控的krbtgt账户哈希加密的，当我们拥有域控的krbtgt账户哈希时，可以自己制作KRB_AS_REP::Ticket::EncryptedData用于后续的身份认证，黄金票据其实指的就是KRB_AS_REP::Ticket

注意一：KRB_AS_REP::Ticket::EncryptedData::EncryptionKey字段等于KRB_AS_REP::EncryptedData::EncryptionKey字段，KRB_AS_REP::EncryptedData字段是用客户端哈希进行加密的。在正常的身份认证过程当中客户端使用自己的哈希解密KRB_AS_REP::EncryptedData值以获得KRB_AS_REP::Ticket::EncryptedData::EncryptionKey值，用于解密后续身份认证过程中产生的KRB_TGS_REP::EncryptedData字段，在黄金票据制作中自己伪造一个EncryptionKey放进KRB_AS_REP::Ticket::EncryptedData::EncryptionKey即可。

注意二：mimikatz工具制作黄金票据需要域SID，这是因为KRB_AS_REP::Ticket::AuthorizationData字段是微软设计的PAC，PAC结构里面需要域组SID，而域组SID由域SID+组标识组成，比如域SID+500表示域管组。

0x09 白银票据

原理：kerberos协议认证过程中KRB_TGS_REP消息返回的KRB_TGS_REP::Ticket::EncryptedData是使用服务账户（域用户或计算机账户，取决于SPN设置在域用户对象还是计算机对象）哈希加密的，当我们拥有服务账户的哈希之后，可以自己制作KRB_TGS_REP::Ticket::EncryptedData用于后续的身份认证，白银票据其实指的就是KRB_TGS_REP::Ticket。

注意一：白银票据能利用成功的前提是服务不验证PAC，当服务验证PAC时白银票据是无法利用成功的。

0x10 MS14068

PAC结构：https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-pac/21181737-74fd-492c-bfbd-0322993a9061

文章：https://daiker.gitbook.io/windows-protocol/kerberos/3#0x00-qian-yan

原理：PAC中的校验和生成如果使用HMAC系列的算法是需要服务账户哈希和krbtgt哈希作为算法的key的，但由于PAC中的服务器校验和与KDC校验和可以使用MD5算法，这就导致没有服务账户哈希和krbtgt账户哈希用户也可以自己制作PAC。

注意一：PAC是放置在KRB_AS_REP::Ticket::AuthorizationData字段中的，而KRB_AS_REP::Ticket字段是经过krbtgt哈希加密的，我们没有krbtgt哈希，构造出的PAC按理说无法填充到被krbtgt加密的Ticket的AuthorizationData字段中，但是很巧妙可以利用KRB_TGS_REP消息的生成的逻辑构造出来。KRB_TGS_REP::Ticket::EncryptedData的生成会把KRB_TGS_REQ::enc-authorization-data填充进去，KRB_TGS_REQ::enc-authorization-data是我们客户端可控的，而KRB_TGS_REP::Ticket是用服务账户的哈希进行加密的，所以我们需要把KRB_TGS_REQ::sname设置为krbtgt账户，这样我们就可以把构造好的PAC填充到被krbtgt加密的Ticket的AuthorizationData字段中了。

0x11 RPC 协议

（1）RPC 编程文档：https://learn.microsoft.com/zh-cn/windows/win32/rpc/rpc-start-page

（2）RPC 协议文档：https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-rpce/290c38b1-92fe-4229-91e6-4fc376610c15?redirectedfrom=MSDN

0x12 DCOM 协议

（1）COM 使用：https://github.com/gh0stkey/Binary-Learning/blob/master/DiShui/0-Beginner/8-COM%E7%BB%84%E4%BB%B6.pdf

（2）DCOM 协议：https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dcom/4a893f3d-bd29-48cd-9f43-d9777a4415b0

0x13 各类 potato 提权原理

https://jlajara.gitlab.io/Potatoes_Windows_Privesc

0x14 WinRM 协议

（1）WinRM 协议文档：https://learn.microsoft.com/zh-cn/windows/win32/winrm/portal

0x15 WMI 协议

（1）WMI 协议文档：https://learn.microsoft.com/zh-cn/windows/win32/wmisdk/wmi-start-page

0x16 Zerologon

（1）概念验证

（2）Zerologon 漏洞原理

Netlogon 协议是一种 RPC 接口，Netlogon 协议提供的方法有两类，一类是需要经过 Netlogon 协议身份认证过后才可调用的方法，一类是不需要经过 Netlogon 协议身份认证即可调用的方法。而 Netlogon 协议身份认证可以根据协商标志选择身份认证过程中计算凭证时使用的算法，而其中的算法之一 AES_CFB8 存在缺陷，结合 Netlogon 协议的认证过程可以绕过 Netlogon 协议的身份认证，导致可以在没有凭据的情况下调用 Netlogon 协议的所有方法。

（3）攻击路径

利用 AES_CFB8 算法缺陷绕过 Netlogon 协议的身份认证
身份认证后调用 Netlogon 协议的 NetrServerPasswordSet2 方法重置域控机器账户的密码为空
使用空密码进行 Dcsync
恢复域控的密码防止域控脱离域

（4）注意到的细节

在完成 Netlogon 协议的身份认证之后，调用 NetrServerPasswordSet2 方法需要传递 Authenticator 参数， Authenticator 参数在服务器即域控还会进行一个验证，这个验证也是通过 AES_CFB8 缺陷进行绕过。
调用 NetrServerPasswordSet2 方法需要在 ClearNewPassword 参数传递加密的新密码，加密使用 AES_CFB8 算法导致可以在不知道加密密钥的情况下构造空密码的密文。
Netlogon 协议身份认证后的通信默认是经过签名的，通过协商标志可以使身份认证后的通信不需要经过签名，所以概念验证设置协商标志为 0x212fffff
AES_CFB8 算法缺陷利用成功有概率性，尝试两千次可以达到99.96%概率

（5）重置域控机器账户密码为空后需要及时恢复域控密码以避免域控脱离域，原因是活动目录存储的域控机器密码和本机lsass进程存储的域控机器密码不一样导致的。

（6）恢复域控密码的手法

（7）Zerologon漏洞的Relay利用手法

（8）修复方案

（9）日志特征

（10）链接博文/文档

0x17 sAMAccountName spoofing

（1）概念验证

（2）CVE-2021-42278

漏洞允许机器账户的名称（名称由sAMAccountName属性标识）不以 $ 符号结尾

（3）CVE-2021-42287

在进行 S4U2self 请求时如果没找到 TGT 票据标识的机器账户，则会在机器账户后加上 $ 符号再进行查找

（4）sAMAccountName spoofing 漏洞原理

sAMAccountName spoofing 漏洞是由 CVE-2021-42278 和 CVE-2021-42287 漏洞组成的一条攻击路径。使用 CVE-2021-42278 漏洞我们可以创建一个机器账户且对这个机器账户的sAMAccountName属性和serviceprincipalname属性有写权限。通过对机器账户的sAMAccountName属性修改为域控机器账户去除$符号然后使用修改过后的机器账户通过 AS_REQ 请求 TGT 票据。请求完 TGT 票据后再修改机器账户的sAMAccountName属性为任意值之后使用 S4U2self 请求 ST 票据。在KDC处理 S4U2self 请求时根据 TGT 票据标识的机器账户进行查找用户，此时由于我们的机器账户已经更改掉sAMAccountName属性了导致没查找到对应用户，这时候KDC会在机器账户后加上 $ 再进行查找，此时查找到的是域控的机器账户，然后KDC用域控的机器账户哈希生成 ST 票据，此时这个 ST 票据是可以用于模拟特定客户端针对域控特定服务进行请求的。

（5）攻击路径

使用 CVE-2021-42278 漏洞我们可以创建一个机器账户
清除新创建的机器账户的serviceprincipalname属性（这是由于在修改sAMAccountName属性时会同步更新serviceprincipalname属性导致和域控的serviceprincipalname属性冲突，通过清除机器账户的serviceprincipalname属性来避免）
通过 LDAP 协议修改创建的机器账户的sAMAccountName属性值为域控机器账户的sAMAccountName属性去掉 $ 符号
通过 AS_REQ 请求 TGT 票据
通过 LDAP 协议修改创建的机器账户的sAMAccountName属性为任意值
通过 S4U2self 请求域控的机器账户哈希生成的 ST 票据

（6）概念验证中的扫描漏洞是否存在模块是如何工作的呢

通过能否成功请求不携带 PAC 的 TGT 票据来判断，在 CVE-2021-42287 漏洞的修复中可以知道它的原理。在安装 CVE-2021-42287 补丁后不允许请求不携带 PAC 的 TGT 票据。

这里的扫描只是判断了是否安装 CVE-2021-42287 补丁而没有判断是否安装 CVE-2021-42278 补丁

（7）修复方案

安装 CVE-2021-42287 补丁和 CVE-2021-42278 补丁，在安装了 CVE-2021-42278 补丁之后由普通域用户创建的机器账户的sAMAccountName属性需要以$结尾
将 Machine Account Quota 设置为0以阻止普通域用户创建机器账户或者修改SeMachineAccountPrivilege特权的权限（从SeMachineAccountPrivilege中删除Authenticated Users并添加Domain Admins或另一组允许的帐户）

（8）日志特征

（9）链接博文/文档

https://exploit.ph/cve-2021-42287-cve-2021-42278-weaponisation.html

0x18 CVE-2022-26923

（1）概念验证

（2）CVE-2022-26923 漏洞原理

使用 Machine 模板向 AC 申请证书时 AC 会把请求者的 dNSHostName 属性嵌入到生成的证书中，使用生成的证书请求 TGT 票据时 KDC 会从证书取出镶嵌的 dNSHostName 属性值并查找 sAMAccountName 属性值和取出值匹配的账户，最后使用查找到的账户完成 TGT 票据生成。通过把机器账户的 dNSHostName 属性设置为 DC 的 dNSHostName 属性值可以达到伪造 DC 的效果。

（3）攻击路径

使用普通域账户创建一个机器账户，普通域用户对创建的机器账户有dNSHostName 属性和serviceprincipalname属性的写权限
通过 LDAP 协议修改机器账户的dNSHostName 属性为 DC 的dNSHostName 属性值，修改dNSHostName 属性时会同时修改serviceprincipalname属性值，因为serviceprincipalname属性值引用了dNSHostName 属性值，所以需要清除serviceprincipalname属性值或者删去serviceprincipalname属性值中引用dNSHostName 属性的部分
使用 Machine 模板向 AC 申请证书
使用申请的证书请求 TGT 票据，生成的票据标识的是 DC 机器账户

（4）为什么在攻击路径的第四步中不需要先更改dNSHostName 属性值再请求 TGT 票据？这是因为在使用证书申请 TGT 票据时 KDC 会从证书取出镶嵌的 dNSHostName 属性值并查找 sAMAccountName 属性值和取出值匹配的账户，最后使用查找到的账户完成 TGT 票据生成，所以机器账户的dNSHostName 属性值对 TGT 票据生成并没有影响，机器账户的dNSHostName 属性值只在证书请求阶段产生作用。

（5）修复方案

在 ADCS 和域控上安装 CVE-2022-26923 补丁，补丁通过在证书中添加对象标识符 (OID) (1.3.6.1.4.1.311.25.2) 进一步对用户进行识别，防止通过dNSHostName 属性值进行欺骗。
通过将 Machine Account Quota 设置为0或者修改SeMachineAccountPrivilege特权的权限禁止普通域账户创建机器账户来阻断攻击路径，但这会有一定的绕过风险。

（6）日志特征

（7）链接博文/文档

0x19 bypassUAC

https://www.anquanke.com/post/id/216808

https://github.com/hfiref0x/UACME

无文件bypassUAC：https://enigma0x3.net/2016/08/15/fileless-uac-bypass-using-eventvwr-exe-and-registry-hijacking/

0x20 各类exec原理

（1）PsExec 概念验证

（2）PsExec 攻击路径

连接服务器 SMB 服务
通过 SMB 服务上传 PSEXESVC.exe 文件到服务器
连接服务器的服务控制管理器
通过服务控制管理器创建一个执行文件为 PSEXESVC.exe 的服务并启动服务
客户端通过管道/其它方式和服务器上新创建的服务通信来管理远程计算机
删除服务器上新创建的服务
删除服务器上的 PSEXESVC.exe 文件

（3）PsExec 通信数据包

（4）特征日志

（5）AtExec 概念验证

（6）AtExec 攻击路径

通过 COM接口/MS-TSCH协议在远程服务器上创建计划任务来执行命令并把命令结果重定向到文件中
删除创建的计划任务
通过 SMB 协议从远程服务器上读取命令执行结果
删除保存命令结果的文件

（7）AtExec 通信数据包

（8）特征日志

（9）SmbExec 概念验证

（10）SmbExec 攻击路径

通过 MS-TSCH协议协议在远程服务器上创建计划任务并执行，计划任务内容为 C:\Windows\system32\cmd.exe /Q /c echo notepad.exe ^> \\127.0.0.1\C$\__output 2^>^&1 > C:\Windows\TEMP\execute.bat & C:\Windows\system32\cmd.exe /Q /c C:\Windows\TEMP\execute.bat & del C:\Windows\TEMP\execute.bat，计划任务的作用是创建一个 execute.bat 批处理文件并执行它，execute.bat 文件的内容为 notepad.exe > \\127.0.0.1\C$\__output 2>&1
删除创建的计划任务
通过 SMB 协议读取 C$\__output 文件获取命令执行结果
删除 C$\__output 文件

（11）SmbExec 通信数据包

（12）特征日志

（13）DcomExec 概念验证

（14）DcomExec 攻击路径

获取远程服务器 ShellWindows/ShellBrowserWindow/MMC20 DCOM对象
调用 ShellWindows::ShellExecute、ShellBrowserWindow::ShellExecute、MMC20::ExecuteShellCommand 方法执行系统命令并把命令结果重定向到文件中
通过 SMB 服务读取文件内容获取命令执行结果
删除文件

（15）DcomExec 通信数据包

（16）特征日志

（17）WmiExec 概念验证

（18）WmiExec 攻击路径

连接远程服务器上的 WMI 服务并获取远程服务器的 Win32_Process 对象
调用远程服务器上 Win32_Process 对象的 Create 方法执行命令，命令内容为 cmd.exe /Q /c whoami 1> \\127.0.0.1\ADMIN$\__1683292860.218341 2>&1
通过 SMB 服务读取文件内容获取命令执行结果
删除保存命令结果的文件

（19）WmiExec 通信数据包

（20）特征日志

0x21 bypassApplocker

https://github.com/api0cradle/UltimateAppLockerByPassList

https://www.anquanke.com/post/id/159892

0x22 看一些MicroSoft-kerberos协议的文档

详细看用户服务和约束委派协议规范，细节比较多（反复翻阅

0x23 非约束委派

关于委派类攻击参考这篇文章，比较全面的

微软在非约束委派的实现上使用的是 带有转发的票证授予票证 (TGT)的 Kerberos 委派 机制，流程图在这里的图一

0x24 约束委派

约束委派委派的哪个服务不重要，因为服务在整个 Ticket 结构中位于未加密部分，直接修改即可

S4U2-Self 协议也就是协议转换

0x25 基于资源的约束委派

寻找以机器账户发起认证的原语以拼接资源委派攻击链

微软不认的“0day”之域内本地提权-烂番茄（Rotten Tomato）
NTLM反射添加 msDS-AllowedToActOnBehalfOfOtherIdentity

遇到问题查阅用户服务和约束委派协议规范，反复翻阅

Name		Name	Last commit message	Last commit date
Latest commit History 31 Commits
images		images
pcapng		pcapng
README.md		README.md
smbv1.pcapng		smbv1.pcapng
smbv2.pcapng		smbv2.pcapng
smbv3.pcapng		smbv3.pcapng

hangchuanin/Intranet_penetration_history

Folders and files

Latest commit

History

Repository files navigation

0x00 kerberos协议

0x01 ntlm协议

0x02 看两个项目

0x03 管道

0x04 smb协议

0x05 windows访问控制

0x06 令牌窃取

0x07 SPN扫描&kerberoast

0x08 黄金票据

0x09 白银票据

0x10 MS14068

0x11 RPC 协议

0x12 DCOM 协议

0x13 各类 potato 提权原理

0x14 WinRM 协议

0x15 WMI 协议

0x16 Zerologon

0x17 sAMAccountName spoofing

0x18 CVE-2022-26923

0x19 bypassUAC

0x20 各类exec原理

0x21 bypassApplocker

0x22 看一些MicroSoft-kerberos协议的文档

0x23 非约束委派

0x24 约束委派

0x25 基于资源的约束委派

0x26

About

Resources

Stars

Watchers

Forks